<rjeffries>
had a long (5 hour) drive today. came up with a few new contril-oriebted use cases for Ben NN one we have fast serial connectivity, either wired (lowest cost) or wireless 6LoWPAN with wpwrak atBen and atUSB. exicting future for Ben methinks.
<rjeffries>
s/exicting/exciting
<rjeffries>
anybody around?
<zrafa>
yes me.. but no for long
<rjeffries>
hi
<rjeffries>
Jay7 where in Russia if I might ask?
<webpower>
hi all
<webpower>
what about USB 3?
<webpower>
i must buy a new pc
<webpower>
but all the notebook have usb 2
<kristianpaul>
C99 how i dint realized u existed before ;-) !
<wpwrak>
;-)
<roh>
wpwrak: your mail: what about hemp fibres?!!1! ;)
<kristianpaul>
So not fork even if rtems have posix support for it !!
<wpwrak>
(c gotchas) hah, tell me, will this segfault ?  printf("%d\n", 0["abc"]);
<wpwrak>
(c gotchas) unsigned n = 1; printf("%d\n", n > -1); /* true or false ? */
<kristianpaul>
wpwrak: You should write a book :-)
<kristianpaul>
Or is already somwhere and i dint realize it yet...
<kristianpaul>
how you could try a signed operation with an unsigned variable?
<kristianpaul>
0["abc"] <-- looks strange for me, le me try
<wpwrak>
it's all mentioned in K&R 2nd ed, appendix A ;-)
<kristianpaul>
It dint segfault
<viric>
uhm I didn't know xiangfu packaged offrss. Great.
<kristianpaul>
"offrss is a standalone program that can download your favorite feeds and then show them in your favorite Web browser" where is the www-browser?..
<kristianpaul>
<3 newsbeuter (after several custom configs, tor one of then :-) )
<xMff>
what does  0["abc"]  do? Looks like some null pointer deref
<viric>
kristianpaul: lynx :)
<viric>
xMff: in C?
<xMff>
viric: yes
<kristianpaul>
K&R is  the C programing language....
<viric>
xMff: it translates to:Â Â Â Â Â Â Â Â *(0 + "abc")
<kristianpaul>
But i dint get to Apendix A yet...
<xMff>
ah, yeah
<viric>
where "abc" will be a pointer to somewhere
<xMff>
but what address is "abc" ? I assume "random"... compiler & binary specific
<viric>
yes
<viric>
But I assume it will return 'a'
<viric>
Well, if '0' was taken as a char pointer, of course.
<kristianpaul>
If 'a' is 97 in hex it does
<xMff>
crazy :)
<viric>
hm strange, that '0' is taken as a char pointer
<kristianpaul>
indeed
<viric>
isn't there any cast? Like ((char *) 0)["abc"] ?
<viric>
So, '0' looks like a char pointer.
<viric>
even -Wall does not say anything with gcc
<kristianpaul>
yeah...
<kristianpaul>
hmm wait
<kristianpaul>
valgrind !!
<viric>
?
<viric>
if gcc takes '0' as a char pointer, there is nothing illegal in 0["abc"]
<kristianpaul>
hmm
<kristianpaul>
gotcha?! :-)
<viric>
1["abc"] will be 'b'
<viric>
you know that    *("abc") gives 'a', right?
<viric>
*("abc" + 0) too
<viric>
*("abc" + 1) gives 'b'
<xMff>
so  0["abc"] == "abc"[0]  ?
<viric>
xMff: looks like so. Only because '0' is taken as char pointer.
<viric>
if it was taken as a pointer to anything else, it would not match
<xMff>
interesting construct
<larsc>
x[y] translates to *(y + x)
<viric>
Ah I only now realised that "abc" mandates the char pointer in the pointer arithmetic. It's not the 0, even it may say 0["abc"]
<viric>
all clear
<viric>
Bona nit
<kristianpaul>
noches
<kristianpaul>
hah!, even clang said something..
<larsc>
well it's valid c, why should it ;)
<larsc>
as i said before x[y] is just eyecandy for *(x + y)
<kristianpaul>
is llvm !! ;-)
<wpwrak>
viric: you got it ! the "[]" operator is commutative, just like "+". very logical - and very surprising when you run into it ;-)
<wpwrak>
now go and write code that screws with people's heads :)
<wpwrak>
kristianpaul: have you already figured out the n > -1 ?
<larsc>
unsigned is stronger than signed
<wpwrak>
larsc: that's a way of putting it. if one argument is unsigned, both will be converted to unsigned. so it becomes the equivalent of (unsigned) n > (unsigned) -1
<wpwrak>
this is one of the useful things -Wextra reports