#include <stdio.h> // compiles fine with Pelles C
int main(void) {
double d1, d2, d3;
char* p1, p2, p3;
d1=123.456;
d2=456;
d3=789;
p1="d1=%f"; // format string
printf(p1, d1);
_getch(); // hit any key
}
Output: d1=123.456000
(maybe it's not a bug; maybe it's by design; maybe it's a design flaw like the fall thru in switch/case; maybe ...)
missing return so defaulted to zero.
or what you think you found ?
Hello,
Out of topic but this line should be added to the source code :
#include <conio.h>
Quote_getch function [not standard C]
Purpose:
Reads a character from the console, without echo.
Syntax:
int _getch(void);
Declared in:
<conio.h>
Nope, it's here:
double d1, d2, d3;
char* p1, p2, p3;
d1...d3 are doubles, of course. But only p1 is a char pointer...!
Greetings to Kernighan & Ritchie, you are real geniuses :biggrin:
Quote from: TimoVJL on July 16, 2022, 05:18:47 AM
missing return so defaulted to zero.
No warning, no problem.
Quote from: Vortex on July 16, 2022, 06:29:33 AMthis line should be added to the source code :
#include <conio.h>
Pelles C throws a warning ("warning #2018: Undeclared function '_getch' (did you mean: getc?); assuming 'extern' returning 'int'") but manages to compile the source correctly :cool:
char *p1, *p2, *p3
You are thinking in assembly :biggrin:
Quote from: HSE on July 16, 2022, 08:49:16 AM
char *p1, *p2, *p3
You are thinking in assembly :biggrin:
No, I am thinking in logic:
double d1, d2, d3; // type double: var1, var2, var3
char* p1, p2, p3; // type char*: var1, var2, var3
Any other interpretation is illogical.
Exactly :thumbsup:
So there is no bugs, only a second opinions as usual.
that return thing was changed in C99, without return, it's 0, similar like C++ before that.
char* p1, p2, p3; // type char*: var1, var2, var3
logic is simple, it start with variable base type and allow pointers to type in same line.
Quote from: TimoVJL on July 16, 2022, 10:30:39 PM
char* p1, p2, p3; // type char*: var1, var2, var3
logic is simple, it start with variable base type and allow pointers to type in same line.
Well, no, the logic is not simple, it's plain wrong: what
seem to be three char* are in reality one char* and 2
chars. A recipe for disaster :cool:
@jj2007
when did you decide you were the person to decide the future of C ?
Timo, C has no future:
- fall-through in Switch/Case
- semi;colons;all;over;the;place
- (far) [too] {many} (brackets)
- illogical variable declarations...
Long live assembly :thumbsup:
Quote from: jj2007 on July 15, 2022, 10:11:30 PM
#include <stdio.h> // compiles fine with Pelles C
int main(void) {
double d1, d2, d3;
char* p1, p2, p3;
d1=123.456;
d2=456;
d3=789;
p1="d1=%f"; // format string
printf(p1, d1);
_getch(); // hit any key
}
Output: d1=123.456000
(maybe it's not a bug; maybe it's by design; maybe it's a design flaw like the fall thru in switch/case; maybe ...)
Hi jj2007,
C++
#include <stdio.h> // compiles fine with Pelles C
int main(void) {
double d1, d2, d3;
char* p1, p2, p3;
d1=123.456;
d2=456;
d3=789;
p1="d1=%f"; // format string
p2='d';
p3='c';
printf(p1, d1);
}
msvc x86 19 $SG5656 DB 'd1=%f', 00H
unsigned __int64 `__local_stdio_printf_options'::`2'::_OptionsStorage DQ 01H DUP (?) ; `__local_stdio_printf_options'::`2'::_OptionsStorage
__real@4088a80000000000 DQ 04088a80000000000r ; 789
__real@407c800000000000 DQ 0407c800000000000r ; 456
__real@405edd2f1a9fbe77 DQ 0405edd2f1a9fbe77r ; 123.456
_d3$ = -32 ; size = 8
_d2$ = -24 ; size = 8
_d1$ = -16 ; size = 8
_p1$ = -8 ; size = 4
_p3$ = -2 ; size = 1
_p2$ = -1 ; size = 1
_main PROC
push ebp
mov ebp, esp
sub esp, 32 ; 00000020H
movsd xmm0, QWORD PTR __real@405edd2f1a9fbe77
movsd QWORD PTR _d1$[ebp], xmm0
movsd xmm0, QWORD PTR __real@407c800000000000
movsd QWORD PTR _d2$[ebp], xmm0
movsd xmm0, QWORD PTR __real@4088a80000000000
movsd QWORD PTR _d3$[ebp], xmm0
mov DWORD PTR _p1$[ebp], OFFSET $SG5656
mov BYTE PTR _p2$[ebp], 100 ; 00000064H
mov BYTE PTR _p3$[ebp], 99 ; 00000063H
sub esp, 8
movsd xmm0, QWORD PTR _d1$[ebp]
movsd QWORD PTR [esp], xmm0
mov eax, DWORD PTR _p1$[ebp]
push eax
call _printf
add esp, 12 ; 0000000cH
xor eax, eax
mov esp, ebp
pop ebp
ret 0
_main ENDP
msvc x64 19$SG5202 DB 'd1=%f', 00H
unsigned __int64 `__local_stdio_printf_options'::`2'::_OptionsStorage DQ 01H DUP (?) ; `__local_stdio_printf_options'::`2'::_OptionsStorage
__real@4088a80000000000 DQ 04088a80000000000r ; 789
__real@407c800000000000 DQ 0407c800000000000r ; 456
__real@405edd2f1a9fbe77 DQ 0405edd2f1a9fbe77r ; 123.456
p2$ = 32
p3$ = 33
d1$ = 40
p1$ = 48
d2$ = 56
d3$ = 64
main PROC
$LN3:
sub rsp, 88 ; 00000058H
movsd xmm0, QWORD PTR __real@405edd2f1a9fbe77
movsd QWORD PTR d1$[rsp], xmm0
movsd xmm0, QWORD PTR __real@407c800000000000
movsd QWORD PTR d2$[rsp], xmm0
movsd xmm0, QWORD PTR __real@4088a80000000000
movsd QWORD PTR d3$[rsp], xmm0
lea rax, OFFSET FLAT:$SG5202
mov QWORD PTR p1$[rsp], rax
mov BYTE PTR p2$[rsp], 100 ; 00000064H
mov BYTE PTR p3$[rsp], 99 ; 00000063H
movsd xmm1, QWORD PTR d1$[rsp]
movq rdx, xmm1
mov rcx, QWORD PTR p1$[rsp]
call printf
xor eax, eax
add rsp, 88 ; 00000058H
ret 0
main ENDP
Hi Jochen,
C is yet living. For example, Masm and Uasm are coded with C.
Quote from: jj2007 on July 17, 2022, 03:50:30 AM
Timo, C has no future:
- fall-through in Switch/Case
- semi;colons;all;over;the;place
- (far) [too] {many} (brackets)
- illogical variable declarations...
Long live assembly :thumbsup:
C is bigger than a your playground, don't forget that.
Quote from: jj2007 on July 17, 2022, 03:50:30 AMC has no future
:biggrin: :biggrin: :biggrin: that was funny.
Folks, why are you so damn serious? :greensml: