Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Harry Chapin's grandfather (Score 3, Insightful) 698 698

I'd like to quote Harry Chapin retelling a story of his grandfather.
I wished I had learnt this lesson a lot earlier in life.
"There's two kinds of tired. There's 'good tired' and there's 'bad tired'.
Ironically now, 'bad tired' can be a day that you won, but you won other peoples' battles, you lived other peoples' days, other peoples' agendas, other peoples' dreams and when it's all over there was very little you in there and when you hit the hay at night somehow you toss and turn, you don't settle easy.
'Good tired', ironically enough, can be a day that you lost, but you only have to tell yourself, cause you knew, you fought your battles, you chased your dreams, you lived your days and when you hit the hay at night you settle easy, you sleep the sleep of the just and you can say 'take me away'."

Do listen to the full story.
https://www.youtube.com/watch?...

Programming

The Perils of Developers Hooking Up 278 278

jammag writes "Who better for a developer to love than another developer? Yet as a veteran coder describes, it's not always a good idea for a programmer to fall for another programmer. He describes his experience observing — and getting partially pulled into — a romance within a development team. Part of the problem, perhaps, is that some developers spend so much time buried in code that, well, they quickly find themselves out of their league. Then again, why not love among the code?"

Comment: Re:fp (Score 1) 594 594

The main in C and C++ differ.
The main in C in hosted environments has been either
int main(void) { /*...*/ } or
int main(int argc, char *argv[]) { /*...*/ }
since at least the C89 standard.
http://web.archive.org/web/20050207005628/http://dev.unicals.com/papers/c89-draft.html#2.1.2
C99/C11 Section 5.1.2.2.1
For freestanding environments the standard states that the name and type of the function called at program startup are implementation-defined.
So, yes void main() would be perfectly valid C if the freestanding environment requires it that way.
Obviously gcc doesn't have to support it or any freestanding environment.
I didn't imply it had to, I merely stated that gcc complains about one incorrect main in a hosted environment but not about another in a hosted environment.

The main in C++ in freestanding environments is, again, implementation-defined.
In hosted environments the main shall have a return type of int but its type is implementation-defined.
Any implementation must at least support
int main() { /*...*/ } and
int main(int argc, char *argv[]) { /*...*/ }
Has been like that since the C++98 standard, section 3.6.1.

In C int f(void) is a function with no parameters returning an int,
int f() is a function with no parameter specification returning an int.
They are not the same and should not be treated as such.

So, what we have is GCC supporting the standard, but whose implementation differs from other compilers. The devs made the choice to not support void main and that's perfectly fine. Nearly everybody who declares main as void are doing so in a hosted environment, and warnings/errors and completely justified.

No. What we have is gcc failing to support the most basic part of the C standard, rendering its -W flags at least questionable.
If it can't warn about an improper main, what else is it failing at?
All I really wanted to point out is that using some code and a compiler is no way to verify the standard.
I used main as an example because the OP wrote int main() in his "verification".

Comment: Re:fp (Score 1) 594 594

And regarding the original discussion about uninitialised local variables I agreed with you. But that's because of the standard, not because of how gcc does things.
Regarding gcc's adherence to the standard I gave you the most basic example a compiler should get right but doesn't.
All I'm trying to tell you is that if you want to verify that something is according to the standard, then using a piece of code and a compiler is not the correct way to do it, especially since a compiler can do whatever it wants with all undefined and implementation defined behaviour in the standard.
gcc could have easily chosen to always initialise uninitialised local variables to 0 regardless of optimisations.

Comment: Re:fp (Score 1) 594 594

No, you verified it well enough for gcc.
gcc complains about void main(), which is perfectly valid C in a freestanding environment, so why can't it complain about int main() in a hosted environment?
My best guess is that the gcc devs don't care about the difference between C and C++ mains because int main() is correct C++.
Or they don't know. Or they're just lazy. In any case, if gcc wasn't free and available, I doubt it'd be used as much.

Comment: Re:fp (Score 1) 594 594

You didn't actually verify it by using gcc but you're still correct.
By using gcc you only tested gcc's implementation-defined C behaviour.
If gcc was strictly adhering to the C std it would tell you that int main() is undefined behaviour on hosted environments and implementation-defined on freestanding environments.

"Ninety percent of baseball is half mental." -- Yogi Berra

Working...