Re: [Tinycc-devel] Re : Re: NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread Steffen Nurpmeso 
david.k...@libertysurf.fr wrote in
 <1056826578.320674719.1646081480955.javamail.r...@zimbra30-e5.priv.proxa\
 d.net>:
 |Nope, I get is as well.
 |
 |Since I registered to the mailing list.
 |
 |Regards.

In return.

 --End of <1056826578.320674719.1646081480955.JavaMail.root@zimbra30-e5.p\
 riv.proxad.net>

--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] rv32 support in tcc

2022-02-28 Thread rempas via Tinycc-devel 
27 Φεβ 2022, 21:22 Από nebk2...@gmail.com:

>> I'm not aware of riscv32 32bit porting efforts but someone is perhaps busy 
>> working on it.
>>
>
> I am currently (slowly) working on a port for riscv32. I haven't had
> much free time lately, so progress has sort of stagnated, but the code
> is here
> https://github.com/sellicott/tcc-riscv32/
>
> Thanks,
> -Sam Ellicott
> Soli Deo Gloria
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
Regardless if you had a lot of free time or if you made a big progress, you are 
awesome for working on it. Writing code is hard and you should take your time 
and have fun with it ;)

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

Re: [Tinycc-devel] rv32 support in tcc

2022-02-28 Thread rempas via Tinycc-devel 
27 Φεβ 2022, 19:29 Από eka...@elenq.tech:

>> With that in mind, I suppose that the differences between these two will be 
>> the length of the registers. So someone should be able to modify the TCC's 
>> "RISC-V64" version and make it support the 32-bit RISC-V with a couple of 
>> changes to both the backend and in the frontend (I suppose things like 
>> disabling 8-byte types for example).
>>
>> Any thoughts on that one?
>>
>
> I don't know about TinyCC's internals but RV64 and RV32 are very similar. 
> There are only a couple of opcodes that change and some instructions (loads 
> and stores) have to be adjusted but that's most of it.
>
> In some months I should be reading tinycc's internals so I could give a 
> better answer or even implement this myself but I can't promise anything at 
> the moment.
>
> Cheers,
> Ekaitz
>
Great! Just as I excepted! I was very interested on RISC-V (and still am) but 
unfortunately at this point, I want to make a compiler and I have to start with 
the front-end (and I mean learn how to do it) and then learn how to decode 
instructions (I don't even know assembly properly tbh) and create binaries so I 
should first create and make stable an x86-X64 backend and then I will add 
support for RISC-V.

If the OP can wait some months that you may be able to work together on that. 
Hope you both the best!

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

[Tinycc-devel] Re : Re: NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread david . koch 
Nope, I get is as well.

Since I registered to the mailing list.

Regards.

- Mail d'origine -
De: Steffen Nurpmeso 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 28 Feb 2022 21:28:04 +0100 (CET)
Objet: Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from 
fdopen()

Steffen Nurpmeso wrote in
 <20220228202318.dh447%stef...@sdaoden.eu>:
 |Domingo Alvarez Duarte wrote in
 | <0154ffd1-bddf-9093-038a-b8286f92d...@gmail.com>:
 ||+1 To "just write a tcc_fdopen()"
 |
 |Looking into it i thought adding two missing checks is sufficient.
 |Untested.
 |
 |  https://repo.or.cz/tinycc.git/commitdiff/917aad3bcfbb534875aa6d66609bdb3\
 |  6459460a4

Btw for the last couple of mails (as rarely as i post) i get this
auto-responder

  From: nos...@thenerdshow.com
  To: stef...@sdaoden.eu
  Subject: Re: Your mail to nos...@thenerdshow.com
  Message-Id: 
  Date: Mon, 28 Feb 2022 15:23:30 -0500

  ...
  Henry will be available for speaking engagements, consulting, and other work 
anywhere in the United States _after_ September 15.

which is yet another six months?
Have you all blocked this on your firewalls or am i per se alone
with that?

Thanks,

--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] NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread Steffen Nurpmeso 
Steffen Nurpmeso wrote in
 <20220228202318.dh447%stef...@sdaoden.eu>:
 |Domingo Alvarez Duarte wrote in
 | <0154ffd1-bddf-9093-038a-b8286f92d...@gmail.com>:
 ||+1 To "just write a tcc_fdopen()"
 |
 |Looking into it i thought adding two missing checks is sufficient.
 |Untested.
 |
 |  https://repo.or.cz/tinycc.git/commitdiff/917aad3bcfbb534875aa6d66609bdb3\
 |  6459460a4

Btw for the last couple of mails (as rarely as i post) i get this
auto-responder

  From: nos...@thenerdshow.com
  To: stef...@sdaoden.eu
  Subject: Re: Your mail to nos...@thenerdshow.com
  Message-Id: 
  Date: Mon, 28 Feb 2022 15:23:30 -0500

  ...
  Henry will be available for speaking engagements, consulting, and other work 
anywhere in the United States _after_ September 15.

which is yet another six months?
Have you all blocked this on your firewalls or am i per se alone
with that?

Thanks,

--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] NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread Steffen Nurpmeso 
Domingo Alvarez Duarte wrote in
 <0154ffd1-bddf-9093-038a-b8286f92d...@gmail.com>:
 |+1 To "just write a tcc_fdopen()"

Looking into it i thought adding two missing checks is sufficient.
Untested.

  
https://repo.or.cz/tinycc.git/commitdiff/917aad3bcfbb534875aa6d66609bdb36459460a4

--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] NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread Domingo Alvarez Duarte 

+1 To "just write a tcc_fdopen()"

On 28/2/22 13:46, Steffen Nurpmeso wrote:

Vincent Lefevre wrote in
  <20220228103710.ga33...@zira.vinc17.org>:
  |On 2022-02-28 10:50:29 +0100, grischka wrote:
  |> Christian Jullien wrote:
  |>> Thanks,
  |>> This is unfortunately not the only case where returned value is \
  |>> not tested, just for fdopen, if maintainers agree, we can probably \
  |>> apply:
  |>> Wdyt?
  |>
  |> The rule is, as always:  don't write code that you cannot test.
  |
  |Various other error cases are probably not tested.
  |Has anyone checked code coverage?
  |
  |Testing the code can be done once by adding "fp = NULL;" and checking
  |that the error is correctly handled. Otherwise, perhaps with LD_PRELOAD
  |to define a fdopen wrapper that will simulate an error for some calls.
  |
  |> Can you?
  |>
  |> Otherwise, can we stop suggesting sloppily crafted quick patches
  |> addressing non-existent problems?
  |
  |fdopen() may fail. So this is a real problem. However, the check for
  |errors should be done on the other related function calls too.
  |
  |Not checking errors may yield obscure errors in user code and/or
  |data loss/corruption (this happened to me with GCC, which did not
  |check some write errors, so that data were randomly silently missing
  |on NFS and my scripts were failing with errors difficult to debug).

Let's just write a tcc_fdopen() the same way myriads of projects
create their local xmalloc()?

   #?0|kent:tcc.git$ git grep fdopen mob
   mob:lib/tcov.c:return fdopen (fd, "r+");
   mob:tcccoff.c:f = fdopen(fd, "rb");
   mob:tccelf.c:f = fdopen(fd, "wb");
   mob:tcclib.h:FILE *fdopen(int fildes, const char *mode);
   mob:tccmacho.c:fp = fdopen(fd, "wb");
   mob:tcctools.c:depout = fdopen(1, "w");
   mob:win32/include/stdio.h:  FILE *__cdecl fdopen(int _FileHandle,const char 
*_Mode);
   mob:win32/include/stdio.h:  _CRTIMP FILE *__cdecl _fdopen(int 
_FileHandle,const char *_Mode);
   mob:win32/include/stdio.h:  _CRTIMP FILE *__cdecl _wfdopen(int _FileHandle 
,const wchar_t *_Mode);
   mob:win32/include/stdio.h:  FILE *__cdecl fdopen(int _FileHandle,const char 
*_Format);
   mob:win32/include/tchar.h:#define _tfdopen _wfdopen
   mob:win32/include/tchar.h:#define _tfdopen fdopen
   mob:win32/include/tchar.h:#define _tfdopen _fdopen
   mob:win32/include/wchar.h:  _CRTIMP FILE *__cdecl _wfdopen(int _FileHandle 
,const wchar_t *_Mode);
   mob:win32/lib/msvcrt.def:_fdopen
   mob:win32/lib/msvcrt.def:_wfdopen

Shouldn't take longer than the quarter of an hour.

--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] NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread Steffen Nurpmeso 
Vincent Lefevre wrote in
 <20220228103710.ga33...@zira.vinc17.org>:
 |On 2022-02-28 10:50:29 +0100, grischka wrote:
 |> Christian Jullien wrote:
 |>> Thanks,
 |>> This is unfortunately not the only case where returned value is \
 |>> not tested, just for fdopen, if maintainers agree, we can probably \
 |>> apply:
 |>> Wdyt?
 |> 
 |> The rule is, as always:  don't write code that you cannot test.
 |
 |Various other error cases are probably not tested.
 |Has anyone checked code coverage?
 |
 |Testing the code can be done once by adding "fp = NULL;" and checking
 |that the error is correctly handled. Otherwise, perhaps with LD_PRELOAD
 |to define a fdopen wrapper that will simulate an error for some calls.
 |
 |> Can you?
 |> 
 |> Otherwise, can we stop suggesting sloppily crafted quick patches
 |> addressing non-existent problems?
 |
 |fdopen() may fail. So this is a real problem. However, the check for
 |errors should be done on the other related function calls too.
 |
 |Not checking errors may yield obscure errors in user code and/or
 |data loss/corruption (this happened to me with GCC, which did not
 |check some write errors, so that data were randomly silently missing
 |on NFS and my scripts were failing with errors difficult to debug).

Let's just write a tcc_fdopen() the same way myriads of projects
create their local xmalloc()?

  #?0|kent:tcc.git$ git grep fdopen mob
  mob:lib/tcov.c:return fdopen (fd, "r+");
  mob:tcccoff.c:f = fdopen(fd, "rb");
  mob:tccelf.c:f = fdopen(fd, "wb");
  mob:tcclib.h:FILE *fdopen(int fildes, const char *mode);
  mob:tccmacho.c:fp = fdopen(fd, "wb");
  mob:tcctools.c:depout = fdopen(1, "w");
  mob:win32/include/stdio.h:  FILE *__cdecl fdopen(int _FileHandle,const char 
*_Mode);
  mob:win32/include/stdio.h:  _CRTIMP FILE *__cdecl _fdopen(int 
_FileHandle,const char *_Mode);
  mob:win32/include/stdio.h:  _CRTIMP FILE *__cdecl _wfdopen(int _FileHandle 
,const wchar_t *_Mode);
  mob:win32/include/stdio.h:  FILE *__cdecl fdopen(int _FileHandle,const char 
*_Format);
  mob:win32/include/tchar.h:#define _tfdopen _wfdopen
  mob:win32/include/tchar.h:#define _tfdopen fdopen
  mob:win32/include/tchar.h:#define _tfdopen _fdopen
  mob:win32/include/wchar.h:  _CRTIMP FILE *__cdecl _wfdopen(int _FileHandle 
,const wchar_t *_Mode);
  mob:win32/lib/msvcrt.def:_fdopen
  mob:win32/lib/msvcrt.def:_wfdopen

Shouldn't take longer than the quarter of an hour.

--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] TinyCC does not accept variable-length static qualifier for function parameter arrays

2022-02-28 Thread John Scott 
On Mon, 2022-02-28 at 09:25 +0100, david.k...@libertysurf.fr wrote:
> Gcc allows this, but Gcc is not conformant and creates "extensions" as it see 
> fit.
This is not a GCC extension; it's my understanding that this is pure
C99. N2310 [1] (a C17 draft) 6.7.6.3 says

A declaration of a parameter as "array of type" shall be adjusted to
"qualified pointer to type", where the type qualifiers (if any) are
those specified within the [ and ] of the array type derivation. If the
keyword static also appears within the [ and ] of the array type
derivation, then for each call to the function, the value of the
corresponding actual argument shall provide access to the first element
of an array with at least as many elements as specified by the size
expression.

Correct me if I'm wrong, but isn't argc+1 an expression?

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf


signature.asc
Description: This is a digitally signed message part
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread Vincent Lefevre 
On 2022-02-28 10:50:29 +0100, grischka wrote:
> Christian Jullien wrote:
> > Thanks,
> > This is unfortunately not the only case where returned value is not tested, 
> > just for fdopen, if maintainers agree, we can probably apply:
> > Wdyt?
> 
> The rule is, as always:  don't write code that you cannot test.

Various other error cases are probably not tested.
Has anyone checked code coverage?

Testing the code can be done once by adding "fp = NULL;" and checking
that the error is correctly handled. Otherwise, perhaps with LD_PRELOAD
to define a fdopen wrapper that will simulate an error for some calls.

> Can you?
> 
> Otherwise, can we stop suggesting sloppily crafted quick patches
> addressing non-existent problems?

fdopen() may fail. So this is a real problem. However, the check for
errors should be done on the other related function calls too.

Not checking errors may yield obscure errors in user code and/or
data loss/corruption (this happened to me with GCC, which did not
check some write errors, so that data were randomly silently missing
on NFS and my scripts were failing with errors difficult to debug).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread Christian Jullien 
Hi,

I'm really sorry to hurt you. It looks John had an issue because of unchecked 
returned value, I was just trying to help.
IMHO, if fdopen really fails, as first approach, it's better to have an error 
message than a core dump but you're the maintainer and I respect all your 
decisions, you have probably something better to propose when fdopen fails.
I suppose that, from John point of view, the problem is not non-existent.

M2c.

C. 

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of grischka
Sent: Monday, February 28, 2022 10:50
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] NULL pointer dereference due to unchecked return 
from fdopen()

Christian Jullien wrote:
> Thanks,
> This is unfortunately not the only case where returned value is not tested, 
> just for fdopen, if maintainers agree, we can probably apply:
> Wdyt?

The rule is, as always:  don't write code that you cannot test.

Can you?

Otherwise, can we stop suggesting sloppily crafted quick patches
addressing non-existent problems?

Is that possible, then?

-- gr

> git diff tcc*.c
> diff --git a/tccelf.c b/tccelf.c
> index 507e83c..bd0a1d9 100644
> --- a/tccelf.c
> +++ b/tccelf.c
> @@ -2428,6 +2428,9 @@ static int tcc_write_elf_file(TCCState *s1, const char 
> *filename, int phnum,
>  return -1;
>  }
>  f = fdopen(fd, "wb");
> +if (f == NULL) {
> +tcc_error("Unable to fdopen %s for output", filename);
> +}
>  if (s1->verbose)
>  printf("<- %s\n", filename);
>
> diff --git a/tccmacho.c b/tccmacho.c
> index 57c62c3..f94f976 100644
> --- a/tccmacho.c
> +++ b/tccmacho.c
> @@ -800,6 +800,9 @@ ST_FUNC int macho_output_file(TCCState *s1, const char 
> *filename)
>  return -1;
>  }
>  fp = fdopen(fd, "wb");
> +if (fp == NULL) {
> +tcc_error("Unable to fdopen %s for output", filename);
> +}
>  if (s1->verbose)
>  printf("<- %s\n", filename);
>
>
>
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] 
> On Behalf Of John Scott
> Sent: Monday, February 28, 2022 05:18
> To: tinycc-devel@nongnu.org
> Subject: [Tinycc-devel] NULL pointer dereference due to unchecked return from 
> fdopen()
>
> Hi all,
>
> I found this bug using the oomify tool at https://github.com/tavianator/oomify
>
> The problem can be seen at tccelf.c around line 2430 (f has type FILE*):
>   f = fdopen(fd, "wb");
>   if (s1->verbose)
>   printf("<- %s\n", filename);
>
> #ifdef TCC_TARGET_COFF
>   if (s1->output_format == TCC_OUTPUT_FORMAT_COFF)
>   tcc_output_coff(s1, f);
>   else
> #endif
>   if (s1->output_format == TCC_OUTPUT_FORMAT_ELF)
>   tcc_output_elf(s1, f, phnum, phdr, file_offset, sec_order);
>
> Note that the return value from fdopen() is not checked if it is NULL.
> If the output format is ELF, then tcc_output_elf() expects that f is a valid 
> FILE* variable and passes it to fwrite(), which causes undefined behavior.
>
> I don't know how to fix this, but hope that maybe one of you folks will 
> appreciate this report.
>
>
> ___
> 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


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

Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from fdopen()

2022-02-28 Thread grischka 

Christian Jullien wrote:

Thanks,
This is unfortunately not the only case where returned value is not tested, 
just for fdopen, if maintainers agree, we can probably apply:
Wdyt?


The rule is, as always:  don't write code that you cannot test.

Can you?

Otherwise, can we stop suggesting sloppily crafted quick patches
addressing non-existent problems?

Is that possible, then?

-- gr


git diff tcc*.c
diff --git a/tccelf.c b/tccelf.c
index 507e83c..bd0a1d9 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -2428,6 +2428,9 @@ static int tcc_write_elf_file(TCCState *s1, const char 
*filename, int phnum,
 return -1;
 }
 f = fdopen(fd, "wb");
+if (f == NULL) {
+tcc_error("Unable to fdopen %s for output", filename);
+}
 if (s1->verbose)
 printf("<- %s\n", filename);

diff --git a/tccmacho.c b/tccmacho.c
index 57c62c3..f94f976 100644
--- a/tccmacho.c
+++ b/tccmacho.c
@@ -800,6 +800,9 @@ ST_FUNC int macho_output_file(TCCState *s1, const char 
*filename)
 return -1;
 }
 fp = fdopen(fd, "wb");
+if (fp == NULL) {
+tcc_error("Unable to fdopen %s for output", filename);
+}
 if (s1->verbose)
 printf("<- %s\n", filename);




-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of John Scott
Sent: Monday, February 28, 2022 05:18
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] NULL pointer dereference due to unchecked return from 
fdopen()

Hi all,

I found this bug using the oomify tool at https://github.com/tavianator/oomify

The problem can be seen at tccelf.c around line 2430 (f has type FILE*):
f = fdopen(fd, "wb");
if (s1->verbose)
printf("<- %s\n", filename);

#ifdef TCC_TARGET_COFF
if (s1->output_format == TCC_OUTPUT_FORMAT_COFF)
tcc_output_coff(s1, f);
else
#endif
if (s1->output_format == TCC_OUTPUT_FORMAT_ELF)
tcc_output_elf(s1, f, phnum, phdr, file_offset, sec_order);

Note that the return value from fdopen() is not checked if it is NULL.
If the output format is ELF, then tcc_output_elf() expects that f is a valid 
FILE* variable and passes it to fwrite(), which causes undefined behavior.

I don't know how to fix this, but hope that maybe one of you folks will 
appreciate this report.


___
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] [PATCH] improving solaris/illumos support

2022-02-28 Thread David CARLIER 
> Hello David,

> Funny, I considered to try this port last year, unfortunately my Solaris VM is
> broken I only have true Solaris 10 sparc machines (with of course No chances 
> it
> works on a sparc CPU).

> What is the status of Solaris port after this patch?

It is the initial step for proper support. It would take further steps
to fix tests (e.g. no support for some linkers features, etc)

 thus simplify the reviews.

> Does it works, I think you have some ELF reloc issues (a big classic for a new
> port), do you?

> You missed the correct values for:
> #elif defined(__sun)
> +#define BOUND_TID_TYPE   pid_t
> +#define BOUND_GET_TIDsyscall (SYS_)


True but I did not port bound check, anyway there is no equivalent for
gettid, part the classic pthread_self/getpid.

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

[Tinycc-devel] Re : TinyCC does not accept variable-length static qualifier for function parameter arrays

2022-02-28 Thread david . koch 
At that moment, the line ain't completely parsed and validated.

Hence argc is still unknown to the compiler.

Gcc allows this, but Gcc is not conformant and creates "extensions" as it see 
fit.

Regards.

- Mail d'origine -
De: John Scott 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 28 Feb 2022 08:06:13 +0100 (CET)
Objet: [Tinycc-devel] TinyCC does not accept variable-length static qualifier 
for function parameter arrays

Hi,

Although this is a conformant C99 program, TinyCC chokes on the
following single line program with 'error: argc undeclared':
int main(int argc, char *argv[static argc+1]) {}

If you're not aware, the static qualifier, when used like this,
indicates that argv must point to an array of at least argc+1 elements.
This can be useful for bounds checking or optimization, but TinyCC
should not fail to compile it. Some other functions this can be useful
with are
int getgroups(int s, gid_t[static s]);
int regexec(const regex_t r[restrict static 1], const char s[restrict 
static 1], size_t n, regmatch_t m[restrict static n], int w);


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