[syslinux] boot... round 2

[Thomas Schmitt]

Hi,

Ady wrote:
> Maybe we should rather wait?

This would normally my position, too. If it was only about
some versions of SYSLINUX and gcc.

But the symptoms are so strange that some larger problem
with the switch from gcc 4.9 to gcc 5 has to be feared. This
could affect any C program. My own ones too.

I'm watching Red Hat bug 1234653 with astonishment.

>From the viewpoint of SYSLINUX and general C programming,
success of SYSLINUX production in a particular environment
does not mean that all is well.
If arbitrary (and supposedly correct) code changes can trigger
the problem on gcc 5 or if gcc 4 suppressed a luring bug,
then it will show up again sooner or later.

It would be nice if one could point to some buggy version
of gcc. But until this is proven, one cannot outrule that
some unsafe C snippet in the source code misleads the compiler.


poma wrote:
> O Captain! my Captain! our fearful trip is done,
> The ship has weather’d every rack, the prize we sought is won

There is danger that the next ship can sink already when it
leaves the harbour. Suspicion of teredo navalis.


Adam Williamson wrote:
> So in the end I actually wound up at the same commit poma did - but
> exactly the other way around. [...]  If I build 6.03 plus that
> commit with GCC 5, it works.

C compilation should really not behave this way.
I do this since quite a while and hardly ever hit mad compilers.
But ambiguous C code plus heavy optimizing can yield such results.

Programmer's life in userspace is more comfortable. gdb and
valgrind help a lot.

I now ran on a git clone of SYSLINUX:
  cppcheck --force . > cppcheck.result 2>&1
It issues several accusations (search for "(error)" and
"(warning)"). But i could not spot any relation to command
line composition for the menu.


Have a nice day :)

Thomas