starts note handler
generates fp fault
saves up registers,
finds that we're in FPillegal state, and process
becomes Broken
That conflicts with Go's intent, I've no idea how one addresses it.
Ideally, the kernel should trigger
On Mon Jun 3 12:35:40 EDT 2013, lu...@proxima.alt.za wrote:
starts note handler
generates fp fault
saves up registers,
finds that we're in FPillegal state, and process
becomes Broken
That conflicts with Go's intent, I've no
if by intent, you mean that go is using xmm registers as if they were
general purpose registers, then the solution is to stop doing that.
and there's such a patch already.
No, Go's intent is to minimise runtime surprises. It is possible to
define signal (calling them notes does not change
On Mon Jun 3 13:05:07 EDT 2013, lu...@proxima.alt.za wrote:
if by intent, you mean that go is using xmm registers as if they were
general purpose registers, then the solution is to stop doing that.
and there's such a patch already.
No, Go's intent is to minimise runtime surprises. It is
On Jun 3, 2013, at 10:07 AM, erik quanstrom quans...@quanstro.net wrote:
On Mon Jun 3 13:05:07 EDT 2013, lu...@proxima.alt.za wrote:
if by intent, you mean that go is using xmm registers as if they were
general purpose registers, then the solution is to stop doing that.
and there's such a
On 3 June 2013 18:04, lu...@proxima.alt.za wrote:
No, Go's intent is to minimise runtime surprises.
It's not a runtime surprise to Go programmers, since no ordinary Go code
runs in that note handler.
There's a rather elaborate implementation to convert notes (or signals)
into something
Just a heads-up to 9fans that the Go build for Plan 9 (386 or ARM) now
expects the underlying platform to be updated with the 21-bit runes
fixes from Bell Labs, the pertinent submission has been accepted and
processed.
Being up to date may not improve the build as much as one may wish,
but not
Regarding the latter, Plan 9 does not allow floating point
instructions to be executed within note handling, but erring on the
side of caution also forbids instructions such as MOVOU (don't ask me)
which is part of the SSE(2?) extension, but hardly qualifies as a
floating point instruction.
Regarding the latter, Plan 9 does not allow floating point
instructions to be executed within note handling, but erring on the
side of caution also forbids instructions such as MOVOU (don't ask me)
which is part of the SSE(2?) extension, but hardly qualifies as a
floating point instruction.
or GO could just stop using *OMG-OPTIMIZED* SSE memmove() in the note
handler.
But it would not stop users from doing so, so at minimum we'd have to
detect the abuse and report it, rather than crash.
Saving the entire register space would be expensive for all
well-behaved processes and
movou (movdqu in the manual) is a sse2 data movement instruction.
not all sse2 instructions require that sse be turned on (pause, for example),
but movou uses at least one xmm register so is clearly using the sse
unit, thus requiring that it be turned on.
I see Erik answers my question: xmm
then the note handler does memmove itself modifying XMM0 itself loading
it with something completely different. then note handler finishes
continuing the original programm, then XMM0 would contain the garbage
from the note handler! it would look for the program like if registers
randomly
On Sun, Jun 02, 2013 at 05:54:14PM +0200, lu...@proxima.alt.za wrote:
I should not be doing it rather than give me an incorrect answer that
I then use to fire a ballistic missile at the wrong target?
I knew Google was up to something.
khm
cinap_len...@gmx.de once said:
or GO could just stop using *OMG-OPTIMIZED* SSE memmove()
in the note handler.
This is exactly what I did in my patch. This was just
a regression. Someone changed memmove a few weeks ago.
Nothing to see here.
Anthony
Can Go be used for replacing C in Plan9? Could be a kernel be written
in Go? If it is not possible, what about making a C-like Go? Where
C-like Go means having similar syntax, but not channels, garbage
collection, and other fancy 21st century runtime features; but with no
need for makefiles and
If you remove the features that make go interesting you'd get C without
punctuation symbols.
On May 17, 2013, at 11:51, lamg gort.andres...@gmail.com wrote:
I think it will be nice for Plan9 having such language-compiler, Go
has proved to be an improvement over C in its own niche.
In its own niche is the important point here. Just because writing a kernel or
system utilities can be
In its own niche is the important point here. Just because writing a
kernel or system utilities can be done in Go doesn't mean it should
be. Go isn't even totally stable or feature complete on Plan 9 at
this point. You get the same shit in C on Plan 9 as you do Go plus
it's more stable and
Go's is a great language that makes it easy to write applications of all
sizes well, but its greatest benefit to Plan 9 is the plethora of packages
that make it possible to deal with the numerous Web standards.
On Fri, May 17, 2013 at 9:31 AM, Matthew Veety mve...@gmail.com wrote:
On May 17,
What about lack of makefiles and fast compilation times?, I don´t want
to remove that. The point is making a more practical C, not a
Go--. Go´s grammar is designed for being easy to parse (and is
different), so it wouldn´t be C without punctuation symbols; and Go´s
package system makes the
On May 17, 2013, at 9:07 AM, Nemo nemo.m...@gmail.com wrote:
If you remove the features that make go interesting you'd get C without
punctuation symbols.
Agreed.
I don't see what's the big deal about doing GC In an OS kernel. And the
features that make Go interesting can be useful at the
On 17 May 2013 18:53, lamg gort.andres...@gmail.com wrote:
What about the
preprocessor? Can we get rid of that?
The Plan 9 C compiler does the preprocessor actions during lexical
analysis. It isn't a separate pass.
On Fri, May 17, 2013 at 11:45:06AM -0700, Bakul Shah wrote:
I don't see what's the big deal about doing GC In an OS kernel.
This is a fantastic troll.
khm
On Fri May 17 16:32:47 EDT 2013, kh...@intma.in wrote:
On Fri, May 17, 2013 at 11:45:06AM -0700, Bakul Shah wrote:
I don't see what's the big deal about doing GC In an OS kernel.
This is a fantastic troll.
i don't see the troll here. there is nothing magic about user space.
- erik
On Fri, 17 May 2013 16:31:43 EDT Kurt H Maier kh...@intma.in self
referentially wrote:
This is a fantastic troll.
In response to
On Fri, May 17, 2013 at 11:45:06AM -0700, Bakul Shah wrote:
I don't see what's the big deal about doing GC In an OS kernel.
See
Oh lord this is degenerating to lisp machines.
On May 17, 2013, at 16:42, Bakul Shah ba...@bitblocks.com wrote:
On Fri, 17 May 2013 16:31:43 EDT Kurt H Maier kh...@intma.in self
referentially wrote:
This is a fantastic troll.
In response to
On Fri, May 17, 2013 at 11:45:06AM -0700,
On Fri, 17 May 2013 16:46:25 EDT Matthew Veety mve...@gmail.com wrote:
Oh lord this is degenerating to lisp machines.
And the problem with that is?
On Fri, May 17, 2013 at 02:05:19PM -0700, Bakul Shah wrote:
On Fri, 17 May 2013 16:46:25 EDT Matthew Veety mve...@gmail.com wrote:
Oh lord this is degenerating to lisp machines.
And the problem with that is?
you are a master troll this is awesome
See http://en.wikipedia.org/wiki/Genera_(operating_system)
Look under the Features section.
hey, that's cool. thanks for the reference.
- erik
Go build is failing today and no mention of it in issue tracker. Anyone
else seeing this problem?
...
cmd/go
main.parseMetaGoImports: pc-relative relocation address is too big:
0x10003b677
main.parseMetaGoImports: pc-relative relocation address is too big:
0x100040cf3
main.parseMetaGoImports:
Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.
-rob
I'm experiencing the same problem.
troubleshooting
First
* STATE YOUR ASSUMPTIONS.
* cat /etc/os-release to verify you are not, in fact, running Ubuntu Linux with
a
Plan 9 theme.
* Try the latest ISO image.
-sl
Go build is failing today and no mention of it in issue tracker.
Anyone else seeing this problem?
Same problem here.
cmd/go
main.parseMetaGoImports: pc-relative relocation address is too big: 0x10003b677
main.parseMetaGoImports: pc-relative relocation address is too big: 0x100040cf3
yes.
On Wed, May 1, 2013 at 11:11 AM, Rob Pike robp...@gmail.com wrote:
Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.
-rob
that means you are building from source
in the ld directory, look for assignments to rd-add from calls to e32. two do
not do a cast to int32. try casting those two and let me know if you can
i will be at work in a couple of hours, not on a phone, and can offer more help
then.
-rob
On May
the diagnostic string only appears in one place; it's in this presumably
abandoned patch:
https://codereview.appspot.com/9036046/
On Wed, May 1, 2013 at 11:30 AM, David du Colombier 0in...@gmail.comwrote:
Go build is failing today and no mention of it in issue tracker.
Anyone else seeing
bootes% grep -n 'rp-add' *.[ch] | grep e32
ldelf.c:709: rp-add = e-e32(sect-base+rp-off);
ldmacho.c:807: rp-add = (int32)e-e32(s-p+rp-off) + rp-off + 4 -
secaddr;
ldmacho.c:809: rp-add = (int32)e-e32(s-p+rp-off);
ldpe.c:294: rp-add = (int32)le32(rsect-base+rp-off);
ldpe.c:300: rp-add =
in the ld directory, look for assignments to rd-add from calls to
e32. two do not do a cast to int32. try casting those two and let me
know if you can
I made this change and it doesn't seem to fix the problem.
diff -r 3478ecc801f6 src/cmd/ld/ldelf.c
--- a/src/cmd/ld/ldelf.cWed May 01
found the other instance at line ldelf.c:681; the assignment from e32 is
indirect via add. same results as before.
On Wed, May 1, 2013 at 12:14 PM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
bootes% grep -n 'rp-add' *.[ch] | grep e32
ldelf.c:709: rp-add = e-e32(sect-base+rp-off);
I don't think changing ldelf.c would fix this issue. IIRC we don't use it on
Plan 9.
On May 1, 2013, at 15:25, Skip Tavakkolian skip.tavakkol...@gmail.com wrote:
found the other instance at line ldelf.c:681; the assignment from e32 is
indirect via add. same results as before.
On Wed,
The patch was not abandoned; that message was a codereview glitch.
It's checked in.
We need to find where the bogus relocation is coming from. It *is*
bogus, but the error catching it is new. To make progress, feel free
to comment out the code that prints the error. I'm pretty sure you'll
be
Are you all using 386 or amd64 systems?
Russ
386 here.
On Wed, May 1, 2013 at 1:46 PM, Russ Cox r...@swtch.com wrote:
Are you all using 386 or amd64 systems?
Russ
It would be easier to debug this if there was a way I could log in to
a Plan 9 machine (or virtual machine) capable of compiling and running
the Go distribution. Such public services have existed in the past;
does one exist today? Please contact me privately if you can help.
-rob
Thanks to machines offered by Erik Quanstrom and David du Colombier, I
found the bug. Trivial fix is out for review.
C's usual integer conversions apply.
-rob
2013/4/15 Christopher Nielsen cniel...@pobox.com
A small caveat, I had to use mercurial on x86 (my cpufsauth server is an x86
vmware instance), since there wasn't an arm binary. Other than that, it was
all pretty painless.
One may '9fs sources fcp /n/sources/contrib/yk/5.python
After a little work, I have a Plan 9 dev environment setup. My dreamplug
boots with no problems, and after installing python and mercurial, I was
able to clone the go repo. The build completes fine on 386, but on the
dreamplug I get the errors below. Yes, I know I should probably be running
as a
congrats! which mercurial and python did you install?
On Mon, Apr 15, 2013 at 1:00 AM, Christopher Nielsen cniel...@pobox.com wrote:
After a little work, I have a Plan 9 dev environment setup. My dreamplug
boots with no problems, and after installing python and mercurial, I was
able to clone
This is a known problem with 5c. It cannot switch on vlong. As a stopgap,
you can
change the types of the things being switched on to integer (type, if I
remember right).
G.
On Mon, Apr 15, 2013 at 9:00 AM, Christopher Nielsen cniel...@pobox.comwrote:
After a little work, I have a Plan 9 dev
Thanks! I'm quite pleased to have managed to get this far with a little
weekend hacking.
I followed the directions from
http://mercurial.selenic.com/wiki/Plan9FromBellLabs
Nice doc to whomever wrote it.
So using contrib, I installed the following:
fgb/z
fgb/bz2
fgb/openssl
bichued/python
I'll give that a shot and see if I get different results. It'll have to be
some time tomorrow though. What concerns me is that the error says it can't
find opnames.h when it clearly exists.
On Mon, Apr 15, 2013 at 12:08 AM, Gorka Guardiola pau...@gmail.com wrote:
This is a known problem with
I'm getting something similar on Sheeva. It also looks like there are still
env issues:
sheeva% ./all.rc
# Building C bootstrap tool.
cmd/dist
# Building compilers and Go bootstrap tool for host, plan9/arm.
lib9
libbio
libmach
misc/pprof
cmd/addr2line
cmd/cov
cmd/nm
cmd/objdump
cmd/pack
cmd/prof
I saw the same problem and solved it by setting GOEXPERIMENT=. Not sure
that's the correct solution, but it worked.
I will look at it in more detail tomorrow, if I have time.
--
Christopher Nielsen
They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety.
1) if you don't change the type of type to be int, it will give you bogus
errors, but
the real problem is that some of the files do not compile.
2) opnames.h is autogenerated by dist. IIRC there is no problem with it
(see 1).
3) I have GOEXPERIM set to ''. You need to set a ton of variables, out
go is using switch on vlongs. support for this was backported to plan9 c compiler
some time ago. just update the compilers from sources.
Von: Skip Tavakkolian skip.tavakkol...@gmail.com
/usr/fst/Go1/src/cmd/gc/reflect.c:1022[/usr/fst/Go1/src/cmd/gc/reflect.c:3400] switch _expression_ must
On Mon, Apr 15, 2013 at 10:31 AM, kernel panic cinap_len...@gmx.de wrote:
go is using switch on vlongs. support for this was backported to plan9 c
compiler
some time ago. just update the compilers from sources.
Last time I checked (like a week ago) it did not work with 5c.
G.
yes. you are right, it doesnt work for 5c.
--
cinap
Gesendet: Montag, 15. April 2013 um 10:43 Uhr
Von: Gorka Guardiola pau...@gmail.com
An: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net
Betreff: Re: [9fans] Go Plan9 ARM Dreamplug
On Mon, Apr 15, 2013 at 10:31 AM, kernel panic
Sheeva/Guru -- GOARM=5
RPi -- GOARM=6 or not set (GOARM=6 is default)
Not if DreamPlug is 5 also.
setting GOARCH=arm, etc. before all.rc on an x86 cpu builds Go for x86 and
arm.
On Mon, Apr 15, 2013 at 1:34 AM, Gorka Guardiola pau...@gmail.com wrote:
1) if you don't change the type of type
yes. you are right, it doesnt work for 5c.
Somewhere the 8c fixes for the switch selector were merged together
with other changes and no one has been able to extricate them so they
could be applied to 5c (et al.). I believe that forsyth is looking
into this, but it would be great to have this
GOROOT=/sys/src/golang #where the go repository resides
GOOS=plan9
GOARCH=$objtype
GOHOSTARCH=$cputype
GOBIN=/$objtype/bin
GOPATH=/sys/src/go #wher your go stuff resides
GOARM=5 #or 6 or 7, depending on your machine's support of floating point.
GOEXPERIM=''
Of the above, I think GOROOT is
On 15 April 2013 10:55, lu...@proxima.alt.za wrote:
Somewhere the 8c fixes for the switch selector were merged together
with other changes and no one has been able to extricate them so they
could be applied to 5c (et al.).
Um. No, that's not the problem. In fact, the changes were redone
I have got a 5c that does vlongs, and thus OREGPAIR,
but it won't compile ghostscript yet, so it hasn't been released.
I'm not sure how to phrase this, but presumably the Go version of 5c
has been upgraded to deal with vlong switch selectors: is the Plan 9
version going to differ a lot from the
it's $GOROOT/VERSION.cache. just put whatever you want in there or
bind it from /tmp if you don't want to pollute the non-plan9 side of
things.
On Sun, Apr 14, 2013 at 3:53 PM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
Unfortunately doesn't seem to help:
cpue% ./all.rc
# Building C
thank you minux and andrey.
I realized I needed something in the file; 'touch VERSION' wasn't fooling
it.
On Sun, Apr 14, 2013 at 3:30 PM, andrey mirtchovski
mirtchov...@gmail.comwrote:
it's $GOROOT/VERSION.cache. just put whatever you want in there or
bind it from /tmp if you don't want to
Unfortunately doesn't seem to help:
cpue% ./all.rc
# Building C bootstrap tool.
cmd/dist
go tool dist: FAILED: /bin/hg identify -b:
'/n/zotac/usr/local/go/VERSION.cache' does not exist
abort:: '/bin/abort:' directory entry not found
cpue%
On Sun, Apr 14, 2013 at 12:32 PM, minux
Gorka has made good progress with his port of Go, his implementation
on the Raspberry PI tests to completion and only a few tests are
failing. The outstanding failures are being investigated and will
be corrected.
On the Sheevaplug the problem is a bit more complicated. Gorka and I
are in
We are expecting a release from Bell Labs of Plan 9 with 21-bit runes
replacing the current 16-bit version. This is big and difficult and
almost certainly extremely painful, so I doubt it will be completed
quickly (feel free to surprise me, guys!). I noticed some changes
being applied
In the meantime, I'd like some 9fans who may own a Sheevaplug,
possibly also other ARM equipment supported by Plan 9 - 9fans with
some interest in Go - to try to install Go on their devices.
Can't go be cross-built? Having multiple cross compilers work
right is one of the best things about
On Wed, Apr 10, 2013 at 12:21 PM, lu...@proxima.alt.za wrote:
In the meantime, I'd like some 9fans who may own a Sheevaplug,
possibly also other ARM equipment supported by Plan 9 - 9fans with
some interest in Go - to try to install Go on their devices. The
instructions are detailed in
the process is probably a lot easier with the right cpu type. i think it is
something like:
for each architecture (arm, 386), cpu into a machine with that architecture
and:
for (i in arm 386) {
GOARCH=$i GOBIN=/$cputype/bin ./all.rc
}
for Sheeva/Guru targets, a GOARM=5 is also needed for arm
I have a dreamplug I've been meaning to put Plan 9 on. I should have time
this week to get that done for testing.
--
Christopher Nielsen
They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety. --Benjamin Franklin
The tree of liberty must be refreshed from
Can't go be cross-built? Having multiple cross compilers work
right is one of the best things about plan9's userland.
Yes, it is possible - to answer your question - although I've found
that having Plan 9 as a special, simpler case is actually a (minor)
liability.
I'm not sure how your
these are fixed in 9atom, and not a problem unless you actually use them.
there are a few problems in the libraries, also fixed. mostly in the font
code.
I have little doubt that your efforts will not be overloked, although
I am in no ways speaking for Bell Labs. My assumption is that Bell
Sorry to dredge up an old thread, but did you get any further with
this Lucio? I'm getting a similar error building current Go tip.
Sorry to dredge up an old thread, but did you get any further with
this Lucio? I'm getting a similar error building current Go tip.
Not at all, the timing is pretty good. Gorka (Paurea) is currently
busy with the Go port to Plan 9/arm and he's confident he'll have it
out soon. I haven't
yes, checked and runs on 386, amd64, and arm.
with the 9 tree from sources.
iirc, I had to do some changes for amd64 and gorka had to port to arm.
hth
On Mar 21, 2013, at 6:23 PM, Francisco J Ballesteros n...@lsub.org wrote:
I think Gorka has it running.
At least, it runs in our rpi's.
Fantastic, I'll be waiting on the edge of my seat for this!
This is correct. The go tool supports files with an
extension matching (go|[chsS]|swig(cxx)?|syso).
Sorry to hi-jack the thread here, does the go tool invoke the native
host compiler or the Plan 9-like one for .c files? I guess the same
question applies for .[sS] extensions?
++L
This is correct. The go tool supports files with an
extension matching (go|[chsS]|swig(cxx)?|syso).
Sorry to hi-jack the thread here, does the go tool invoke the native
host compiler or the Plan 9-like one for .c files? I guess the same
question applies for .[sS] extensions?
++L
?c and ?g use the same calling convention, and segmented stacks are
implemented by the linker. You don't need cgo in order to call C code
from Go. Why do you want cgo?
Look at the various C files in the Go standard library, especially
inside runtime. Those are compiled with the Plan 9 compiler
Aram Hăvărneanu ara...@mgk.ro once said:
?c and ?g use the same calling convention, and segmented stacks are
implemented by the linker. You don't need cgo in order to call C code
from Go. Why do you want cgo?
This isn't true. Most of the Plan 9 compilers will pass the
first function argument
?c and ?g use the same calling convention, and segmented stacks are
implemented by the linker. You don't need cgo in order to call C code
from Go. Why do you want cgo?
Look at the various C files in the Go standard library, especially
inside runtime. Those are compiled with the Plan 9
The C compilers in the Go toolchain pass everything on the
stack and return the result in a register.
The Go compilers pass everything on the stack including the
output parameters. No registers are involved in the calling
convention.
That isn't a big deal, in my case, because the language
CGO will generate C code stubs that require gcc to compile.
The gcc generated executable (_cgo_.o in the example bellow) is then
parsed for it's dwarf debug info
(I think) to get import the names and dso's of imported symbols.
Later, when you build an executable using the cgo'd package; 6l will
I need some help getting my mind around what should be a simple issue:
how to connect Go with Plan 9's native toolchain.
To be more specific, I have a port of the OpenLDAP library for Plan 9
that works quite adequately and I would like to access it from GO. I
guess this is true of any similar
On Thu Nov 22 04:03:29 EST 2012, charles.fors...@gmail.com wrote:
usize is indeed the same size as uintptr.
Instead of either for purely integer values, it would be better to
make all integers 64 bit, and use uint and int (for pointer
differences),
but that causes other problems, at the
I hadn't noticed that particularly, but having grep'd the source, I
see it's also used for variables that are counters and numbers of
things.
Is that right too? I suspect it's more out of expediency. Some other
type usage looks odd too. int32 where int would do. Curious.
On 22 November 2012
.B char
can generally be assumed to be a signed value.
What does generally mean here? Is it safe to assume or not?
There are no signed variants of these as they
are not useful where size-specific types are appropriate.
Not useful seems an arbitrary judgment. There are certainly
cases
usize is indeed the same size as uintptr.
Instead of either for purely integer values, it would be better to
make all integers 64 bit
I hope that was intended as a joke. It's not that long ago I was
writing C for a 16-bit processor (in a smart card). I would hate to
lose the meaning of int
On 22 November 2012 11:00, Richard Miller 9f...@hamnavoe.com wrote:
OTOH, it's not worth making special provision for physical memory addresses.
I think that any code which is dealing with those is not likely to be
portable to another architecture for many other reasons. I can't envision
a
To try to clarify: most existing Plan 9 code doesn't worry about the
actual type of sizeof or pointer differences.
They assume int/long or uint/ulong. It's obvious from this discussion
that hardly anyone noticed usize.
Since its introduction years ago, grep shows that only kernel code has
used
Even port refers to
physical addresses (eg, Page)
You're right, I should have thought a bit longer. This is
why my PAE hack for xen only supports 4GB of physical
(well, virtually physical) memory.
I meant, detect code. It's easy to find: just look at libflate, but
there were many more.
On 22 November 2012 11:32, Charles Forsyth charles.fors...@gmail.com wrote:
it's quite
hard to find code (automatically) that assumes they are 32 bits.
New C programmers are often confused by
size_t being unsigned (even experienced ones at times)
Especially experienced ones. My 1978 copy of KR says
The expression sizeof(object) yields an integer equal to the
size of the specified object.
Not unsigned integer. Old habits die hard.
It was in v6 (and a nasty bug):
/*
* sizeof gets turned into a number here.
* Bug: sizeof(structure-member-array) is 2 because
* the array has been turned into a ptr already.
*/
if (op==SIZEOF) {
t1 = length(p1);
p1-op = CON;
p1-type = INT;
On Thu Nov 22 06:01:38 EST 2012, 9f...@hamnavoe.com wrote:
.B char
can generally be assumed to be a signed value.
What does generally mean here? Is it safe to assume or not?
good point.
There are no signed variants of these as they
are not useful where size-specific types are
i put up corrections
- erik
The expression sizeof(object) yields an integer equal to the
size of the specified object.
Not unsigned integer. Old habits die hard.
I feel your pain.
We use lint a lot here and it irritates me greatly when it
grumbles about loss of precision in assignment
from sizeof() or nelem() to an
It was changed in Ritchie's own compiler in v7 as I noted earlier.
It was that, use long, or limit your sizeof'd data to half the 16-bit
address space.
On 22 November 2012 11:54, Steve Simon st...@quintile.net wrote:
I wish I had been in the standards meeting with a big stick when somone
201 - 300 of 479 matches
Mail list logo
