C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

Chris Angelico
I've noticed a number of commits going through that remove C99isms for
the sake of Windows builds. Does that imply that the code must be
exclusively C89, or are there some C99isms that are acceptable?

The only one left now is a dynamic array:

GtkTargetEntry drag_targets[targ->size];

Will this cause problems? If so, what's the preferred idiom - alloca?

I'd like to merge this branch into 8.1 soon, if there are no
objections. I've been using it locally with no problems.

ChrisA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

Martin Nilsson (Coppermist) @ Pike (-) developers forum
I don't know the details, grubba is the one that has been trying to
get 8.1 to build on the existing VC9 Windows build machines. So
anything that doesn't break VC9 is probably fine.

I'm dedicating all my Windows development time* to get VC14 up and
running. If that gets done we can probably go all out C99.

* Windows is boring. It gets maybe 45min per week. There is very slow
  progress, but progress no the less.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

Chris Angelico
In reply to this post by Chris Angelico
On Tue, Dec 13, 2016 at 10:25 AM, Peter Bortas @ Pike  developers
forum <[hidden email]> wrote:
> I don't know the details, grubba is the one that has been trying to
> get 8.1 to build on the existing VC9 Windows build machines. So
> anything that doesn't break VC9 is probably fine.

I'm having trouble finding authoritative information on what VC9
supports (MS don't seem to carry much information on their older
compilers - they carry precious little even on the current ones - so
I'm depending on Stack Overflow), but it looks like VLAs are *not*
supported. Sigh. So I guess I'll change it up. Should I go with
alloca, or does Pike have its own preferred way to do this?

ChrisA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

Martin Nilsson (Coppermist) @ Pike (-) developers forum
I'd be OK with disabling GTK on Windows in 8.1 for now if the
alternative is uglifying your entire codebase. Grubba might need it
for something though, so don't commit anything to that effect until he
gives the go ahead.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

Chris Angelico
In reply to this post by Chris Angelico
On Tue, Dec 13, 2016 at 10:40 AM, Peter Bortas @ Pike  developers
forum <[hidden email]> wrote:
> I'd be OK with disabling GTK on Windows in 8.1 for now if the
> alternative is uglifying your entire codebase. Grubba might need it
> for something though, so don't commit anything to that effect until he
> gives the go ahead.

I'd not be OK with disabling GTK on Windows in 8.1. :) I got it down
to just four lines, and I've commented them out and put C89
equivalents (with alloca) underneath. Some day we (and by "we" I
probably mean "I") can go in, notice that, and switch to the cleaner
version. The change will be pushed (to rosuav/gtk2-drag-drop) as soon
as I figure out why Pike is segfaulting, which seems to be unrelated.

ChrisA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

Chris Angelico
On Tue, Dec 13, 2016 at 10:47 AM, Chris Angelico <[hidden email]> wrote:
> The change will be pushed (to rosuav/gtk2-drag-drop) as soon
> as I figure out why Pike is segfaulting, which seems to be unrelated.

Found it. The GTK build script includes this (massively cut down):

//build_pgtk.pike
void main()
{
  add_constant( "Function", class { } );
  program output_plugin = (program)"doc-pikeref.pike";
}
//doc-pikeref.pike
protected string trim_xml( string what )
{
  object p = Parser.XML.Tree.parse_input(what);
}

Some change in the past month or so meant that this causes a big fat
noisy segfault at some point where Parser.XML.Tree tries to use
something from the Function module, and all hell breaks loose. I've
fixed it by renaming the class (it's entirely within the GTK build
process, so that shouldn't have any ill effects), but it's curious
that this can cause Pike to actually segfault.

Anyway, the gtk2-drag-drop branch is now C89 compliant, so far as I
can tell. If I don't hear any objections, I'll merge it - can always
revert if something horrific happens.

ChrisA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

Arne Goedeke
In reply to this post by Chris Angelico
On 12/13/16 00:33, Chris Angelico wrote:

> I'm having trouble finding authoritative information on what VC9
> supports (MS don't seem to carry much information on their older
> compilers - they carry precious little even on the current ones - so
> I'm depending on Stack Overflow), but it looks like VLAs are *not*
> supported. Sigh. So I guess I'll change it up. Should I go with
> alloca, or does Pike have its own preferred way to do this?

I know that alloca does not play well with longjmp. This is not a
problem on all compilers, but specifically windows builds can break when
using both in the same function. I suppose that C99 arrays are ok once
they are correctly supported. I removed alloca from sprintf for instance
some years ago because it could crash on windows. Use heap memory if you
can.

arne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C99, dynamic arrays, and branch rosuav/gtk2-drag-drop

Chris Angelico
On Tue, Dec 13, 2016 at 9:58 PM, Arne Goedeke <[hidden email]> wrote:

> On 12/13/16 00:33, Chris Angelico wrote:
>
>> I'm having trouble finding authoritative information on what VC9
>> supports (MS don't seem to carry much information on their older
>> compilers - they carry precious little even on the current ones - so
>> I'm depending on Stack Overflow), but it looks like VLAs are *not*
>> supported. Sigh. So I guess I'll change it up. Should I go with
>> alloca, or does Pike have its own preferred way to do this?
>
> I know that alloca does not play well with longjmp. This is not a
> problem on all compilers, but specifically windows builds can break when
> using both in the same function. I suppose that C99 arrays are ok once
> they are correctly supported. I removed alloca from sprintf for instance
> some years ago because it could crash on windows. Use heap memory if you
> can.

*facepalm* Windows builds can break on anything. Okay. You know what?
I have another solution. It's not like you're often going to need very
many targets. Until C99 is supported, these now use a fixed-size
buffer, and check the array length. So instead of risking a crash,
they just limit you to ten in the incoming array.

ChrisA
Loading...