Peter Dennis - Sustaining Engineer wrote:
> Roland Mainz wrote:
> > Peter Dennis - Sustaining Engineer wrote:
> >> Roland Mainz wrote:
> >>> "Peter D. Dennis" wrote:
> >>>>> Chris Quenelle wrote:
> > [snip]
> >>>> As it stands my current work is to get the cw wrapper to understand the
> >>>> new SS12
> >>>> command flags (-m64 and the associated -xarch= subflag) and clean up the
> >>>> lint
> >>>> noise.
> >>> What is the current status of the project ?
> >> The cw work is done and putback to snv_80. Currently working on getting
> >> a clean lint build.
> >
> > Ok...
> > ... BTW: Please don't try to cleanup the lint stuff for { libshell,
> > libcmd, libpp, libdll, libsum, libast } ... that's what needs to be done
> > on our&&AT&T's side...
>
> Nope - I've no intention of doing that part - it is the kernel that has
> a bunch of lint complaints that needs to be cleaned.
Ok...
[snip]
> > 2. The change is less dangerous then you think - much work has already
> > been done by the "compile OS/Net with gcc"-project and most of the code
> > just works out of the box (gcc makes string literals read-only by
> > default and requires an explicit option ("-fwriteable-strings") for
> > gcc3.x (gcc4.x no longer provides an option for this, e.g. string
> > literals are read-only without a way to change it)) and the "error
> > condition" is very simple: You either get a SIGSEGV or the code works.
> > That reduces IMHO the "risk" down to a minimum.
>
> Yes but the problem with a SIGSEGV is was it the compiler change or
> was it the new flag ?
That's easy - if you write to a string _literal_ it's the "-xstrconst"
option which caused the trouble. But as I said earlier the "compile
OS/Net with gcc" project caught AFAIK almost all instances and I doubt
there are more than one or two bugs hidden in the whole tree. And
testing a "-xstrconst"'tified libc/libnsl/libsocket with { boot, run,
shutdown } Solaris+CDE and bulitin OS/Net didn't show any problems which
means at least this part is already safe.
[snip]
> > ... not much... except that the VLA ("variable length array") support is
> > still busted (which worked in Sun Studio 10, the switch to Studio 11
> > then broke it...)
>
> Do you happen to have a bug id for that ?
Welcome to CR #6575435 ("ctf tools cannot handle C99 VLAs ("variable
length arrays")") - you'll find lots of wailling from my side since the
original ksh93-intergration putback was designed for OS/Net compiled
with Studio 10 and it was quite a ... uhm... shock that it didn't work
anymore at some point... ;-(
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
