Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-03-16 Thread Muktha Narayan

Hi Kalle,
Kalle Olavi Niemitalo wrote:

Kalle Olavi Niemitalo  writes:

  

However I've now looked at C99 6.7.4p3 and it specifically
mentions modifiable objects.  So I wonder if we could just put
some const in elinks_ulongcat to make the objects unmodifiable.



I have pushed this change to the elinks-0.11 branch
and it is included in last night's snapshot.
http://elinks.cz/download/elinks-current-0.11.tar.gz

Can you report whether the snapshot builds on OpenSolaris?
  

Yes, the snapshot builds successfully on OpenSolaris.

Regards
Muktha

___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-03-14 Thread Kalle Olavi Niemitalo
Kalle Olavi Niemitalo  writes:

> However I've now looked at C99 6.7.4p3 and it specifically
> mentions modifiable objects.  So I wonder if we could just put
> some const in elinks_ulongcat to make the objects unmodifiable.

I have pushed this change to the elinks-0.11 branch
and it is included in last night's snapshot.
http://elinks.cz/download/elinks-current-0.11.tar.gz

Can you report whether the snapshot builds on OpenSolaris?


pgpP4I3k8GYzv.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-03-04 Thread Kalle Olavi Niemitalo
Muktha Narayan  writes:

> Kalle Olavi Niemitalo wrote:
>> Because ELinks is violating a C99 requirement, rather than
>> something specific to Sun, I don't think it's right to make an
>> exception for the Sun compiler.  Instead, we should make the
>> functions not inline and measure how that affects the speed.
>> If it hurts too much, then define e.g. static inline int
>> inline_elinks_ulongcat() and make both int elinks_ulongcat()
>> and int elinks_longcat() call that.  GCC should generate from
>> that approximately the same code as from the current sources.
>>   
> Attached  is the modified patch incorporating the above
> comments. Please confirm if the patch is acceptable.

Actually I hoped to see some numbers about how much slower
ELinks gets if you just drop the inline specifiers.  If the
difference is negligible, then it is better not to complicate
the source code with wrappers.

However I've now looked at C99 6.7.4p3 and it specifically
mentions modifiable objects.  So I wonder if we could just put
some const in elinks_ulongcat to make the objects unmodifiable.

diff --git a/src/session/session.c b/src/session/session.c
index 3cd9b5a..73459f2 100644
--- a/src/session/session.c
+++ b/src/session/session.c
@@ -423,7 +423,9 @@ load_ecmascript_imports(struct session *ses, struct 
document_view *doc_view)
 #define load_ecmascript_imports(ses, doc_view)
 #endif
 
-inline void
+/* can't be inline according to C99 6.7.4p3 because it uses static
+ * request_frameset() and is not itself static */
+void
 load_frames(struct session *ses, struct document_view *doc_view)
 {
struct document *document = doc_view->document;
diff --git a/src/util/conv.c b/src/util/conv.c
index 68ae545..d29a61d 100644
--- a/src/util/conv.c
+++ b/src/util/conv.c
@@ -52,9 +52,9 @@ elinks_ulongcat(unsigned char *s, unsigned int *slen,
unsigned char fillchar, unsigned int base,
unsigned int upper)
 {
-   static unsigned char unum[]= "0123456789ABCDEF";
-   static unsigned char lnum[]= "0123456789abcdef";
-   unsigned char *to_num = (unsigned char *) (upper ? &unum : &lnum);
+   static const unsigned char unum[]= "0123456789ABCDEF";
+   static const unsigned char lnum[]= "0123456789abcdef";
+   const unsigned char *to_num = (upper ? unum : lnum);
unsigned int start = slen ? *slen : 0;
unsigned int nlen = 1; /* '0' is one char, we can't have less. */
unsigned int pos = start; /* starting position of the number */


pgpAfuS5pv5di.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-03-04 Thread Mark A. Carlson

Kalle,

Is this acceptable?

-- mark

Muktha Narayan wrote:

Hi,

Kalle Olavi Niemitalo wrote:

"Mark A. Carlson"  writes:

  

+#if defined (__SUNPRO_C)
+static inline void
+#else
 inline void
+#endif
 load_frames(struct session *ses, struct document_view *doc_view)



This looks like .
That bug was reported against ELinks 0.12pre1 though.
I haven't heard about such problems with 0.11.5 before.
It looks like 0.10.6 has the same bug; can you confirm?

  

Yes, elinks-0.10.6 has the same bug (in session.c and conv.c).

Because ELinks is violating a C99 requirement, rather than
something specific to Sun, I don't think it's right to make an
exception for the Sun compiler.  Instead, we should make the
functions not inline and measure how that affects the speed.
If it hurts too much, then define e.g. static inline int
inline_elinks_ulongcat() and make both int elinks_ulongcat()
and int elinks_longcat() call that.  GCC should generate from
that approximately the same code as from the current sources.
  
Attached  is the modified patch incorporating the above comments. 
Please confirm if the patch is acceptable.


Regards
Muktha


--
  * Mark A. Carlson *
Sr. Architect

*Systems Group*
Phone x69559 / 303-223-6139
Email mark.carl...@sun.com



___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-03-03 Thread Muktha Narayan

Hi Kalle,

Please let know if the modified patch is acceptable.

Regards
Muktha

Muktha Narayan wrote:

Hi,

Kalle Olavi Niemitalo wrote:

"Mark A. Carlson"  writes:

  

+#if defined (__SUNPRO_C)
+static inline void
+#else
 inline void
+#endif
 load_frames(struct session *ses, struct document_view *doc_view)



This looks like .
That bug was reported against ELinks 0.12pre1 though.
I haven't heard about such problems with 0.11.5 before.
It looks like 0.10.6 has the same bug; can you confirm?

  

Yes, elinks-0.10.6 has the same bug (in session.c and conv.c).

Because ELinks is violating a C99 requirement, rather than
something specific to Sun, I don't think it's right to make an
exception for the Sun compiler.  Instead, we should make the
functions not inline and measure how that affects the speed.
If it hurts too much, then define e.g. static inline int
inline_elinks_ulongcat() and make both int elinks_ulongcat()
and int elinks_longcat() call that.  GCC should generate from
that approximately the same code as from the current sources.
  
Attached  is the modified patch incorporating the above comments. 
Please confirm if the patch is acceptable.


Regards
Muktha


___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-02-24 Thread Muktha Narayan

Hi,

Kalle Olavi Niemitalo wrote:

"Mark A. Carlson"  writes:

  

+#if defined (__SUNPRO_C)
+static inline void
+#else
 inline void
+#endif
 load_frames(struct session *ses, struct document_view *doc_view)



This looks like .
That bug was reported against ELinks 0.12pre1 though.
I haven't heard about such problems with 0.11.5 before.
It looks like 0.10.6 has the same bug; can you confirm?

  

Yes, elinks-0.10.6 has the same bug (in session.c and conv.c).

Because ELinks is violating a C99 requirement, rather than
something specific to Sun, I don't think it's right to make an
exception for the Sun compiler.  Instead, we should make the
functions not inline and measure how that affects the speed.
If it hurts too much, then define e.g. static inline int
inline_elinks_ulongcat() and make both int elinks_ulongcat()
and int elinks_longcat() call that.  GCC should generate from
that approximately the same code as from the current sources.
  
Attached  is the modified patch incorporating the above comments. Please 
confirm if the patch is acceptable.


Regards
Muktha
--- elinks-0.11.5/src/session/session.c	2009-02-23 03:50:00.852630689 -0800
+++ elinks-0.11.5-new/src/session/session.c	2009-02-23 03:49:38.152751175 -0800
@@ -423,7 +423,7 @@ load_ecmascript_imports(struct session *
 #define load_ecmascript_imports(ses, doc_view)
 #endif
 
-inline void
+void
 load_frames(struct session *ses, struct document_view *doc_view)
 {
 	struct document *document = doc_view->document;
--- elinks-0.11.5/src/util/conv.c	2009-02-23 03:54:45.261625605 -0800
+++ elinks-0.11.5-new/src/util/conv.c	2009-02-24 00:10:55.615002838 -0800
@@ -46,8 +46,8 @@
  */
 /* The function returns 0 if OK or width needed for the whole number to fit
  * there, if it had to be truncated. A negative value signs an error. */
-int inline
-elinks_ulongcat(unsigned char *s, unsigned int *slen,
+static int inline
+inline_elinks_ulongcat(unsigned char *s, unsigned int *slen,
 		unsigned long number, unsigned int width,
 		unsigned char fillchar, unsigned int base,
 		unsigned int upper)
@@ -103,8 +103,17 @@ elinks_ulongcat(unsigned char *s, unsign
 	return ret;
 }
 
+int 
+elinks_ulongcat(unsigned char *s, unsigned int *slen,
+		unsigned long number, unsigned int width,
+		unsigned char fillchar, unsigned int base,
+		unsigned int upper)
+{
+	inline_elinks_ulongcat(s, slen, number, width, fillchar, base, upper);
+}
+
 /* Similar to elinks_ulongcat() but for long number. */
-int inline
+int 
 elinks_longcat(unsigned char *s, unsigned int *slen,
 	   long number, unsigned int width,
 	   unsigned char fillchar, unsigned int base,
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


Re: [elinks-dev] Patch for porting Elinks to OpenSolaris

2009-02-18 Thread Kalle Olavi Niemitalo
"Mark A. Carlson"  writes:

> +#if defined (__SUNPRO_C)
> +static inline void
> +#else
>  inline void
> +#endif
>  load_frames(struct session *ses, struct document_view *doc_view)

This looks like .
That bug was reported against ELinks 0.12pre1 though.
I haven't heard about such problems with 0.11.5 before.
It looks like 0.10.6 has the same bug; can you confirm?

Because ELinks is violating a C99 requirement, rather than
something specific to Sun, I don't think it's right to make an
exception for the Sun compiler.  Instead, we should make the
functions not inline and measure how that affects the speed.
If it hurts too much, then define e.g. static inline int
inline_elinks_ulongcat() and make both int elinks_ulongcat()
and int elinks_longcat() call that.  GCC should generate from
that approximately the same code as from the current sources.


pgpYxI2JCG2hq.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


[elinks-dev] Patch for porting Elinks to OpenSolaris

2009-02-18 Thread Mark A. Carlson

Elinks folks,

The enclosed is a patch for porting Elinks to OpenSolaris.

Please acknowledge acceptance of this patch.

-- mark
--
  * Mark A. Carlson *
Sr. Architect

*Systems Group*
Phone x69559 / 303-223-6139
Email mark.carl...@sun.com



--- elinks-0.11.5/src/session/session.c 2009-01-28 03:26:15.595141936 -0800
+++ elinks-0.11.5-new/src/session/session.c 2009-01-28 03:26:06.024737496 
-0800
@@ -423,7 +423,11 @@ load_ecmascript_imports(struct session *
 #define load_ecmascript_imports(ses, doc_view)
 #endif
 
+#if defined (__SUNPRO_C)
+static inline void
+#else
 inline void
+#endif
 load_frames(struct session *ses, struct document_view *doc_view)
 {
struct document *document = doc_view->document;
--- elinks-0.11.5/src/util/conv.c   2009-01-28 03:26:35.022458560 -0800
+++ elinks-0.11.5-new/src/util/conv.c   2009-01-28 03:25:09.212165347 -0800
@@ -52,8 +52,13 @@ elinks_ulongcat(unsigned char *s, unsign
unsigned char fillchar, unsigned int base,
unsigned int upper)
 {
+#if defined (__SUNPRO_C)
+   unsigned char unum[]= "0123456789ABCDEF";
+   unsigned char lnum[]= "0123456789abcdef";
+#else
static unsigned char unum[]= "0123456789ABCDEF";
static unsigned char lnum[]= "0123456789abcdef";
+#endif
unsigned char *to_num = (unsigned char *) (upper ? &unum : &lnum);
unsigned int start = slen ? *slen : 0;
unsigned int nlen = 1; /* '0' is one char, we can't have less. */
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev