Re: [Tinycc-devel] Include path bug (Was: Re: plans to 0.9.27)

[Steffen Nurpmeso]

i wrote:
 |avih  wrote:
 |  ...
 ||Now to build something bigger. Let's take tmux, which also uses stdarg:
 |
 |I am also using tmux again since on this box, sad for libevent,
 |but so it is, and needed by other software so present anyway.
 ...
 |tmux is more responsive and paints faster, and selection seems to

So i have to take this back, if i work in vim(1) with
a horizontally splitted window tmux cursor movement becomes very
slow sometimes, slower than i was used to get with screen for
sure.  (All this over ssh.)  The only other difference is
AlpineLinux versus ArchLinux.

  ...
 |Because is picked once started i think.  I have even placed my
 |.screenrc in configs.git/.home.attic last week because i was all
 |so positive about it, and then tmux is also installed by default
 |on NetBSD and OpenBSD etc.:
 |
 |  ?128[steffen@essex configs.git]$ git log --pretty=format:%ad \
 |.home.attic/.screenrc
 |  2017-10-10 23:51:13 +0200

..but have not changed this nonetheless.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Include path bug (Was: Re: plans to 0.9.27)

[Steffen Nurpmeso]

avih  wrote:
  ...
 |Now to build something bigger. Let's take tmux, which also uses stdarg:

I am also using tmux again since on this box, sad for libevent,
but so it is, and needed by other software so present anyway.
I only have not actualized the webpage accordingly yet, also
because i switched to OpenNNTPD (Alpine 3.6 version buggy and
cannot use constraints, edge ok) and have even started to use
OpenSMTPD instead of Postfix locally, so i was waiting whether all
that reaches the server before updating my webpage.

tmux is more responsive and paints faster, and selection seems to
work less error prone (trailing whitespace on lines where there is
none).  I miss the possibility to have a floating status line that
does not rip off from the screen, but overlays for the given time
and then simply disappears.  And the history is not compressed,
but this no more a problem is for me, also i could imagine memory
being advised as potentially unused when stored in history, or
whatever.  Otherwise it is great.  Of course it was implemented
from scratch whereas GNU screen has a decade old history, right?
Also i miss the possibility to specify the history when creating
windows instead of doing

  set-option -g history-limit 0
  new-window -t MIAUI -d -n edit -t 1 -c~ vim -u ~/.vimrc
  set-option -g history-limit 42000

Because is picked once started i think.  I have even placed my
.screenrc in configs.git/.home.attic last week because i was all
so positive about it, and then tmux is also installed by default
on NetBSD and OpenBSD etc.:

  ?128[steffen@essex configs.git]$ git log --pretty=format:%ad \
.home.attic/.screenrc
  2017-10-10 23:51:13 +0200

The new "choose-tree -w" with the preview is pretty cool, and can
luckily be disabled, too!
Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Include path bug (Was: Re: plans to 0.9.27)

[Steffen Nurpmeso]

grischka  wrote:
 |Steffen Nurpmeso wrote:
 ..
 |> mildly.  I guess the right thing to do would be to strip all paths
 |> which are also in the system array from the user paths present in
 |> the non-standardized $C_INCLUDE_PATH environment variable, even if
 |> that means that this possibly changes the search order desired by
 |> the user anyway.  
 |
 |Not quite.  Really the only thing you can do is to clean up that
 |suspicions system path cruft from the C_INCLUDE_PATH on YOUR OWN
 |computer:

I see no reason to start screaming.  If that would have been the
first reply of yours i would have looked around earlier for sure.
I think it was clear that i have no idea of compiler internals.

 |- /usr/local/include
 |- /usr/include
 |
 |Search order is fixed by conventions, and the built-in system
 |paths have least priority.
 |
 |This implies that it is the compiler's business to set them and
 |that at the same time the user is allowed to override them, even
 |if then the compiler stops to work at all.
 |
 |Therefor your C_INCLUDE_PATH cannot work for tinycc.
 |
 |(The public version of tinycc that is, and as long as it needs
 |its own stdarg.h / does not have __builtin_va_stuff)

I have recreated my patch locally, because i need tcc for working.
I do not know whether gcc and pcc create __builtin sauce in code,
but they do the right thing here, regardless of my C_INCLUDE_PATH.
gcc does not read its own stdarg.h, therefore i would assume it.
tcc also works like this on GNU LibC systems, by the way.

But hey, the bug has been reported, a simple-minded patch has been
rejected, i am eagerly awaiting a true fix.

Ciao.  And have a nice weekend, of course.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Include path bug (Was: Re: plans to 0.9.27)

[grischka]

Steffen Nurpmeso wrote:

Hello.

So i thought about it and come back to apologize.  At least
mildly.  I guess the right thing to do would be to strip all paths
which are also in the system array from the user paths present in
the non-standardized $C_INCLUDE_PATH environment variable, even if
that means that this possibly changes the search order desired by
the user anyway.  


Not quite.  Really the only thing you can do is to clean up that
suspicions system path cruft from the C_INCLUDE_PATH on YOUR OWN
computer:

   - /usr/local/include
   - /usr/include

Search order is fixed by conventions, and the built-in system
paths have least priority.

This implies that it is the compiler's business to set them and
that at the same time the user is allowed to override them, even
if then the compiler stops to work at all.

Therefor your C_INCLUDE_PATH cannot work for tinycc.

(The public version of tinycc that is, and as long as it needs
its own stdarg.h / does not have __builtin_va_stuff)

See also:
  https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html#index-CPATH
  https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html

-- gr



Or the approach of hell, use a token and once
that is seen first, "temporarily rewind to global scope" and
inject the necessary typedef there, or simply generate builtin
knowledge of the type as such, not backed with anything a user can
see when looking through the headers.  I for one do not like any
of those, not even the first, though.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Include path bug (Was: Re: plans to 0.9.27)

[Steffen Nurpmeso]

Hello.

So i thought about it and come back to apologize.  At least
mildly.  I guess the right thing to do would be to strip all paths
which are also in the system array from the user paths present in
the non-standardized $C_INCLUDE_PATH environment variable, even if
that means that this possibly changes the search order desired by
the user anyway.  Or the approach of hell, use a token and once
that is seen first, "temporarily rewind to global scope" and
inject the necessary typedef there, or simply generate builtin
knowledge of the type as such, not backed with anything a user can
see when looking through the headers.  I for one do not like any
of those, not even the first, though.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Include path bug (Was: Re: plans to 0.9.27)

[Steffen Nurpmeso]

Hi.

grischka  wrote:
 |grischka wrote:
 |Now, I fixed that, plus the ARM signed char test, plus some other
 |stuff.
 |
 |Also, I removed the win32/Makefile (thanks to Christian's OK),
 |and the VIP patch (it is just not how it should work), and the
 |-iwithprefix option (what was the point without -iprefix).
 |
 |Moreover, there is
 |* a patch to tccelf.c to avoid DT_TEXTREL unless really required
 |* a nifty one in tccasm.c to avoid the 'p3' forward label from
 |   alloca86_64.S being put into dynsym with a relocation (huh?)
 |* and the (sig)set variable in tcctest.c was made static to
 |   avoid some issue with inline asm that I didn't try to fix
 |* no diff -I option anymore to make tests work with busybox
 |* a patch to tccrun.c for better selinux support.
 |
 |With these changes, tcc now seems to build and pass all tests
 |cleanly on Alpine musl x86_64 standard-grsec and vanilla too,
 |configured with
 |./configure --config-musl --with-selinux
 |optionally also with
 |--disable-static and/or --cc=tcc (once it was installed)

Does not work for me at all on musl system:

  ?0[steffen@essex tmp]$ ldd zt
  ldd: zt: Not a valid dynamic program

As well as:

  ?0[steffen@essex nail.git]$ make
  make[1]: Entering directory '/home/steffen/src/nail.git'
CC accmacvar.o
  In file included from ./accmacvar.c:52:
  In file included from ./nail.h:2615:
  ./nailfuns.h:425: error: invalid type
  make[1]: *** [mk-config.mk:120: accmacvar.o] Error 1
  make[1]: Leaving directory '/home/steffen/src/nail.git'
  make: *** [makefile:20: build] Error 2
  ?2[steffen@essex nail.git]$ sed -e 425p -e d nailfuns.h
  FL voidn_verr(char const *format, va_list ap);

and even worse:

  ?0[steffen@essex nail.git]$ tcc -print-search-dirs
  install: /home/steffen/usr/opt/tcc/lib/tcc
  include:
/home/steffen/usr/include
/home/steffen/usr/include
/usr/local/include
/usr/include
/home/steffen/usr/opt/tcc/lib/tcc/include

Quite honestly i am pissed.  How can stdarg.h ever be found here
when there is one in /usr/include?  If this is not supposed to
work like that, why provide stdarg.h at all?  Are there systems
without stdarg.h in /usr/include?  See, i do not know.  You gave
that token thing maybe "hint", but why should this be handled in
compiler internal code when all that is missing is inclusion of
a compiler/ABI specific header first?  That is the road to hell!

Note that i never was actually interested in compiler or kernel
programming.  Actually not true, but i never found time to come
down to this, as there was always other code i had to deal with
and wanted to get straight.  But if i had, i would really dig into
the problems and find a solution of my own, how tiny and/or
ridiculous that would have been -- as if given an exercise by
Knuth: write an operating system.

I cannot spend time on tcc, i just have none.  I admire there is
tcc, and pcc, and people working on them.  But you are active in
this project for a decade and a half or so, at least, you know the
code or even saw it growing, live, i did not.  And then
i nonetheless spent more than two hours trying to inject code,
which was a total waste of time.  Maybe some day i will have the
time to do that, but i have other projects that i want to take
care of and, differently to tcc, can do so.
Thank you.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel