[Edbrowse-dev] Using C99?

[Edbrowse-dev] Using C99?

[Karl Dahlke]

I would very much like to port edbrowse to windows someday,
and so would like the option of compiling under visual studio.

Yes the bool type would be especially nice since we do use it for the cpp files,
and using eb_bool for the c files is a bit of a workaround that I don't especially like.
Some of your other changes would be nice as well.
Maybe you can do a little research and see which ones
we can make while preserving a reasonable amount of portability,
including, someday, the option of a windows port.

Someone once ported this to mac, thus the makefile.osx,
but that was a long time ago and nobody has kept up with it.
makefile.osx is I'm sure out of date by now.

Karl Dahlke

Re: [Edbrowse-dev] Using C99?

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

On Wed, Aug 06, 2014 at 04:45:44PM -0400, Karl Dahlke wrote:
> I would very much like to port edbrowse to windows someday,
> and so would like the option of compiling under visual studio.

Perhaps, though as ms aren't updating C support any more I'm not sure about the
idea of targeting vs. At the end of the day mingw or sigwin are probably
better targets for Windows porting in my opinion.

> Yes the bool type would be especially nice since we do use it for the cpp files,
> and using eb_bool for the c files is a bit of a workaround that I don't especially like.
> Some of your other changes would be nice as well.
> Maybe you can do a little research and see which ones
> we can make while preserving a reasonable amount of portability,
> including, someday, the option of a windows port.

I'd say we first need to decide whether we want to target newer c compilers on
Windows or stick to the microsoft visual studio compiler.
As you've probably gathered from the previous part of this email,
I'd personally rather target modern,
updated compilers on the basis that compiling for Windows will already require
installing all sorts of custom libraries which may or may not play nicely with visual studio.
In particular, I think the ability to use C99 and asprintf (which isn't standard but is
available in various environments) outweigh a Windows port which is still a way
off from being worked on.

As for the move to C++, I think if we allow ourselves to use the extensions
provided by C99 and other common non-standard extensions (e.g.
asprintf), we can get many of the benefits of such a move without the massive rewrite.

> Someone once ported this to mac, thus the makefile.osx,
> but that was a long time ago and nobody has kept up with it.
> makefile.osx is I'm sure out of date by now.

That's a good point, I'll have a look into this as I've got an up-to-date mac
system at home.
Perhaps I may even be able to put together a homebrew package as well,
but first I need to work out if smjs will compile and is packaged for this to happen.

On the subject of releases, what's the status of the release currently?

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] Using C99?

[Paul Onyschuk]

On Thu, 7 Aug 2014 11:30:36 +0100
Adam Thompson wrote:

> Perhaps, though as ms aren't updating C support any more I'm not sure
> about the idea of targeting vs. At the end of the day mingw or sigwin
> are probably better targets for Windows porting in my opinion.

A lot of software is doing that already.  Some IDEs for Windows like
Code::Blocks are targeting mingw by default, since GCC is on-part if
not better than compilers provided by Microsoft.

> As for the move to C++, I think if we allow ourselves to use the
> extensions provided by C99 and other common non-standard extensions
> (e.g. asprintf), we can get many of the benefits of such a move
> without the massive rewrite.

asprintf() is definitly nice to have if you looking for string
manipulation with dynamic allocation.

snprintf() returns the number of characters that would have been output
if the size were unlimited, so that truncation can be detected.  This
way buffer overflows can be detected and prevented compared to strcat()
and strcpy().
 
> That's a good point, I'll have a look into this as I've got an
> up-to-date mac system at home.
> Perhaps I may even be able to put together a homebrew package as well,
> but first I need to work out if smjs will compile and is packaged for
> this to happen.

Mac OS X shouldn't be a problem.  What differs is location of includes
and libraries for linking.  Their libc isn't so modern, but I wouldn't
worry about it. Beside that default compiler is Clang.

-- 
Paul Onyschuk

Re: [Edbrowse-dev] Using C99?

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Thu, Aug 07, 2014 at 12:49:34PM +0200, Paul Onyschuk wrote:
> On Thu, 7 Aug 2014 11:30:36 +0100
> Adam Thompson wrote:
> 
> > Perhaps, though as ms aren't updating C support any more I'm not sure
> > about the idea of targeting vs. At the end of the day mingw or sigwin
> > are probably better targets for Windows porting in my opinion.
> 
> A lot of software is doing that already.  Some IDEs for Windows like
> Code::Blocks are targeting mingw by default, since GCC is on-part if
> not better than compilers provided by Microsoft.

Yeah, I've got a friend who uses Code::Blocks and I've compiled under Windows
using mingw before and been happy with the results.

> > As for the move to C++, I think if we allow ourselves to use the
> > extensions provided by C99 and other common non-standard extensions
> > (e.g. asprintf), we can get many of the benefits of such a move
> > without the massive rewrite.
> 
> asprintf() is definitly nice to have if you looking for string
> manipulation with dynamic allocation.

Agreed, I've used it extensively in prior projects.

> snprintf() returns the number of characters that would have been output
> if the size were unlimited, so that truncation can be detected.  This
> way buffer overflows can be detected and prevented compared to strcat()
> and strcpy().

Yeah, which would be useful in various parts of the code.
I also like the idea of being able to use stdbool.h.

> > That's a good point, I'll have a look into this as I've got an
> > up-to-date mac system at home.
> > Perhaps I may even be able to put together a homebrew package as well,
> > but first I need to work out if smjs will compile and is packaged for
> > this to happen.
> 
> Mac OS X shouldn't be a problem.  What differs is location of includes
> and libraries for linking.  Their libc isn't so modern, but I wouldn't
> worry about it. Beside that default compiler is Clang.

The includes stuff isn't really the problem here,
it's more that I'm happy enough to maintain an edbrowse package (or formula in
homebrew speak) but not an smjs one since I'm not a Mozilla developer and thus
keeping up with the changes in smjs would probably be a large amount of work
which I simply don't have time for.

I'm definitely going to look at the osx makefile though since that should just
be a case of fixing include locations and possibly compiler flags.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] Using C99?

[Paul Onyschuk]

Is edbrowse targeting C89 or there is a reason why some of the newer
features aren't used?  That could be the case very well, if a
compilation under Visual Studio is supported, since Microsoft decided
not to update C beyond C89.

I'm asking, because there are places, where code could be improved a
little bit.  Some examples:

- designated initializer for arrays in message.c
- bool type from <stdbool.h> instead of eb_bool (this is cosmetic)
- snprintf() for string manipulation with bound checking, could be
  used to replace strcpy()/strcat() where performance isn't important
- strdup() instead of cloneString(), asprintf() instead of
  appendString () and prependString(). Those aren't standard functions,
  but enviroment with C99 compiler should provide them.

But then according to readme, edbrowse is moving toward C++, so maybe
it isn't worth the hustle.

-- 
Paul Onyschuk