Re^5: porting C code to Perl

Sorry, for some reason I believed

int nines    = 0;
int predigit = 0;
[download]

to read

int nines, predigit = 0;
[download]

instead and this was what I was talking about (and showcasing in the tests). In this situation '= 0' adds nothing.

For 'predigit, nines = 0;': You are totally correct - it does make a difference. I assume this is a bug in the original code which has not been spotted when verifying the result using the widely deployed Eyeball Mark 1 test suite.

Comment on Re^5: porting C code to Perl Select or Download Code

Replies are listed 'Best First'.
Re^6: porting C code to Perl by RonW (Parson) on Oct 25, 2017 at 20:47 UTC
As you discovered, `int nines, predigit = 0;` is not the same as `int nines = 0; int predigit = 0;` [download] I'm surprised `int nines, predigit = 0;` is even valid C syntax.¹ However, `nines, predigit = 0;` is valid C syntax, but treats `nines` and `predigit = 0` as 2 separate expressions. `nines` is evaluated in void context (so, the warning you got), while `0` is evaluated in an integer context and then assigned to `predigit` (effectively, `predigit` is in lvalue context). An alternate syntax that would have zero'd both is `nines = predigit = 0;` which may be what the author intended to write (but he should have gotten the warning). --- ¹ Note that in Perl, `my ($nines, $predigit) = 0;` will init `$nines` to 0 and leave `$predigit` undefined. Also, it doesn't give a warning.	[reply] [d/l] [select]
Re^6: porting C code to Perl by marioroy (Prior) on Oct 24, 2017 at 15:57 UTC
Hi Mark::Thomas. I apologize for not providing the compiler warning, initially with line number.	[reply]
Re^6: porting C code to Perl by Anonymous Monk on Oct 24, 2017 at 17:53 UTC
By the way, the explicit initialization to zero can make a difference in some cases. From gcc docs: `-fno-zero-initialized-in-bss` If the target supports a BSS section, GCC by default puts variables that are initialized to zero into BSS. This can save space in the resulting code. This option turns off this behavior because some programs explicitly rely on variables going to the data section—e.g., so that the resulting executable can find the beginning of that section and/or make assumptions based on that. This could be useful, for example if you want your "hot" global variables to go together in .data section for improved data locality. But there are better ways to achieve the same.	[reply] [d/l]